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Delivery Overview 

Today Sellers are constricted by the rigidity of Fannie Mae's delivery/servicing systems. There 
are products that cannot be delivered through "normal" channels (MORNET) because the product 
has data elements not currently supported in our 2000 character format or the Sellers must enter 
the data more than once into more than one system (e.g. DU and Delivery). The Core 
Infrastructure Project will integrate key aspects of Fannie Mae's underwriting system (DU), pncmg 
system (Pricing Engine), and delivery system (Delivery) to allow for the following: 

• Single point of entry (one channel to deliver) 

• Multiple methods of data transmission 

• DU/Delivery connection 

Currently the Fannie Mae Delivery System is very inflexible when it comes to all data and edits to 
be performed on the loan data being received from the Seller. The new system will have a flexible 
edit engine, allowing for quick additions, changes, and severity levels going forward as well as the 
ability to quickly add required data elements as necessary to allow for Fannie Mae business to 
grow in areas where we are currently restricted by system inflexibilities. The goal of the Delivery 
system is to reduce the amount of time it takes to introduce a new product. 

The Delivery system will allow the Seller and Fannie Mae to access and view the same data and 
an Acquisition file containing all Acquisition data elements will be sent to the Servicer of the loan. 

1. Methods of Delivery 

1.1. Data Delivery Methods 

The Delivery System will allow the Seller three different ways to deliver. The new Delivery 
System will allow the seller to: 

1.1.1. Logon to the Fannie Mae website and edit loans/pools using the edit engine without 
the intent of immediately delivering the loans/pools for purchase or pooling. With this 
option, the seller will have the ability to submit data without a Fannie Mae loan 
number. The seller can request the Fannie Mae Delivery business edits to be run 
(data format edits will always be run automatically). The loans will be edited and the 
results will be displayed back to the seller. The seller will have the ability to update 
the data and re-edit this data as necessary. 

1 . 1 .2. Submit the loan/pool data to the system, run the data format edits, but do not run 
the business edits for the loans/pools. The purpose of this option is for sellers to 
send loan data to Fannie Mae to hold until further notice. The loans will only be 
subject to business editing and purchase/pooling when the seller clicks the "edit" or 
"submit" button. Once the seller successfully edits and then submits the data, the 
system will generate a Fannie Mae loan number for each of the loans. 

1 .1 .3. "Traditional Delivery Method" - Submit the loan/pool data to the system, run the 
format and business with the intent to purchase or securitize. The system will 
generate the Fannie Mae Loan Number for each of the loans. 



1 .2. Post Submission 
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1.2.1- After submitting data, the system will communicate errors in submission through 
edits that can be addressed by either Fannie Mae or the Seller. 

2. Data Capture Sources 

2.1 . Data Capture Scenarios 

2.1 .1 . The system will allow for data capture in the following methods: 

• Upload 

• On-Line 

2.1 .2. The system will allow the seller to combine all products in one file format OR to 
deliver unique products (i.e. Reverse Mortgages) on separate file formats. 

2.1 .3. To provide maximum flexibility the system needs to allow for the import of the 
following existing file formats: 

• Fannie Mae 2000 Character File ASCI Text Format (for Cash and Pool 
Submissions) 

• Reverse Mortgage File Format 

• Energy Loan File Format 

• Additional Data Elements - Required Borrower and Property Data (Housing 
Goals Data) 

2.1 .4. If the Seller selects one of the product specific formats listed above, they do not 
have to select a product type. The system will identify the product based on the file 
layout. 

2.1 .5. Provide an "expanded" 2000 character file ASCI text Format. 

2.1 .6. Allow for new .xml -based files that can be customized to accommodate all 
products. 

2.1 .7. If the Seller selects the generic format, the system will prompt the user to select the 
product type (i.e. Reverse) so that the loan can be identified as a specific product for 
editing. 

2.1 .8. If the Seller has made an execution decision the system will allow the Seller the 
flexibility to deliver data elements which comprise the Plan Number and Special 
Feature Codes or to delivery the Plan Number and Special Feature Code values. A 
translator must be built to take a summary level fields (such as Plan Number) and 
break it down to the lower level attributes. 

3. Processing 
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3.1 . Data Processing Scenarios 

3 11 If the seller uses batch submission and if the loan is not in a Certified or in a Ready 
' " for Purchase status, the system will facilitate the seller to submit a transmission and 
overwrite an existing data or allow them to append the existing loan by filling in 
missing data. The loan will require re-editing after the update or overwrite. 

3.1 .2. Address Scrubbing and Geo Coding 

After capturing address information that passes basic edit validation (format edits), the 
system performs address scrubbing and geo coding to standardize the address 
information and supplement existing address data. The outcome is a standard format for 
address data that wiil be used in data submission for delivery. If the delivery system does 
not send a correct file to the scrubbing system, a warning is logged and data is submitted. 
If the seller indicates that the scrubbing system has not come back with the correct 
address they may edit captured data or submit the address data with warnings. (See 
Delivery' Appendix B for detailed information on Address Scrubbing Data) 

Address Scrubbing 

3.1 .2.1 . Provide Address Scrubbing at the time data is captured and format edits are 
run. 

312 2 As part of the submission process, the data is scrubbed so that it reflects a 
legal address as defined by the U.S. Postal Service. 

312 3 A flat DAT file with address information and a trigger TRG file are sent 
' ' ' through ftp to the Address Scrubbing Service input directory. These files should 
be generated by the Delivery System based on the data captured from the 
Seller. .DAT file contains the following information: 

• Loan ID 

• Street Address 

• City Name 

• State Abbr. 

• Zip Code (w/leading zeros or zero-filled if blank) 

312 4 The Address Scrubbing Service interfaces with Sagent third-party software, 
which recognizes and normalizes the data in order to find a property. This is 
NOT an interface from the Delivery system. The Delivery system interfaces only 
with the Address Scrubbing Service, which then interfaces to Sagent software. 

312 5 The Address Scrubbing Service returns two files to an output directory 
queue, to be retried by ftp. The .OUT file has the scrubbed address (if 
available) The .RPT is a report file that has additional statistics about the job. It 
indicates if the .OUT file is ready to be read by the Delivery system. If the file 
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sent to the service was of the wrong format, an .ERR file is returned instead of 
the .OUT file. This error should never occur, however, if the Delivery system is 
generating .DAT and .TRG files automatically. 

3.1 .2.6. The Delivery system should retrieve files from the Address Scrubbing 
Service output queue and write a .DON file to the input queue to indicate 
retrieval of the files. 

3.1 .2.7. The Seller should have the ability to view scrubbed data to verify 
correctness before data submission. 

3. 1 .2.8. The system should generate warnings if the property does not exist in their 
database, but this should not prohibit the loan data from being delivered. There 
are situations, especially for new developments, when there is a time lag for the 
new addresses to be entered in the Postal Service database. Warnings should 
also be generated based on the QMS Match Quality Code. A flag or warning 
message should be appended to the scrubbed data based on the error type 
returned in the QMS Match Quality Code. 

3.1 .2.9. Scrubbed data should be appended to the original captured Seller address 
data. The first five fields of the .OUT file contain the original input file information 
(identical to .DAT information). The scrubbed data fields include: 

• Scrubbed Street Address 

• Scrubbed City Name 

• Scrubbed Two letter state abbreviation 

• 9 digit ZIP code 

• QMS Match Quality Code 

• QMS Location Quality Code 

3.1 .2.10. The Seller must have the ability to acknowledge possible errors in the 
address and continue submission or cancel and edit captured data before re- 
running edits and address scrubbing process. 

Geo Coding 

3.1 .2.1 1 . Provide Address Scrubbing at the time data is captured and format edits are 
run. Geo Coding takes place concurrently with Address Scrubbing, using the 
same Sagent third-party software, and can be turned off if the Geo Coding 
information is no longer necessary by using a code in the trigger file. 

3.1 .2.12. The Geo Coding function helps in providing additional geographic 
information on the property. This includes: 

• USPS Range Record type 
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Longitude (millionths) 
Latitude (millionths) 

Tract (State FIPS + County FIPS + Tract) 
Block Group, Block Metropolitan Statistical Area Number 
FIPS Place ID 

Central City (Y or N) Congressional District (State Abbr + Dist.) 
Ward (DC only) 
Minor Civil Division FIPS Code 
American Indian (Tribal Land) Code 

3 1 .2.1 3. The system should generate warnings and append to the Geo Coding data 
' based on the Location Quality Code if it returnsrfio location available (denoted as 
an "E"). 

3 1 .2.14. The seller should be able to acknowledge the location quality warning 

before submission. This warning could be displayed concurrent with match code 
warnings with the option of revising before submission. 

3.1 .2.1 5. The system should append Geo Coding data to the original captured data. 

3.1 .3. Loan Limit Validation 

3.1 .3.1 . As loans are captured (either through the manual keying process or at 
upload), the system needs to check to see if the loan currently exists on our 
servicing database. 

3 1 .3.2. If the loan exists and it is NOT a duplicate (i.e. the lien type is not identical), 
add the two Unpaid Principal Balances or Issue Date Unpaid Principal Balances 
at Acquisitions together. 

3.1 .3.3. Validate that the combined balances do not exceed our chartered Loan Limit 
requirements that are in effect at the time the second loan is submitted. 

3.1.4. Duplicate Loan Check 

3. 1 .4. 1 . Perform a duplicate loan check against all execution types and loans stored 
in the Fannie Mae Acquisitions/Servicing database. Duplicate loans can be 
saved in the system but cannot be submitted. 

3. 1 .4.2. The loan information that comprises the Duplicate Key data is TBD. The 
current key is comprised of: Seller Number, Lender Loan ID, Lien Type, 
Participation Percent, Loan type, first Installment Due Date and the Address 
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Information. 

3.1 .4.3. In performing the address check in the duplicate process, the system should 
match against the normalized data from the Address Scrubbing. 

3.2. Delivery Integration with DU and Pricing 

Today, Desktop Underwriter (DU) and the Delivery Systems are not integrated. Sellers do 
not have an automated way to transfer DU data to Delivery. Sellers are required to re-key 
DU data into Delivery or hope that the data being sent to the Fannie Mae Delivery system 
is the data that was actually used to underwrite. The lack of automation and integration 
between DU and Delivery results in 1) sellers having to re-key data entered in DU, into 
Delivery; 2) the potential for sellers to unknowingly deliver incorrect data to Fannie Mae 
(data input errors that have an underwriting/pricing impact); 3) sellers not knowing when 
the DU and Delivery data (key underwriting/pricing) data is not in sync which may result in 
credit related fees; and 4) sellers not having the ability to know the "all in" price (interest 
and credit price). This often results in sellers being charged credit related fees by Fannie 
Mae, which are not actually billed to the seller for days/weeks after the actual delivery. 

The Core Infrastructure Project will integrate key aspects of Fannie Mae's underwriting 
system (DU), pricing system (Pricing Engine), and delivery system (Delivery). For loans 
that were underwritten in DU, sellers will have the ability to transfer DU related data to 
Delivery automatically at their discretion. Sellers will also be notified when/if the data that 
is being delivered does not match the data that was used for underwriting. Specifically, 
sellers will be notified when the underwriting decision has changed and there is an impact 
to the price or fees Fannie Mae will charge them. Sellers will also be shown the "all in" 
price of a loan before the actual purchase or pooling has taken place. This "all in" price will 
itemize the key components of a price. 

All loans that were not previously underwritten in DU will be sent through DU at the time of 
Delivery so that sellers can see what the underwriting decision would have been if they had 
actually underwritten the loan using DU. By sending all non-DU underwritten loans to DU 
at the time of Delivery, Fannie Mae hopes to also get a better understanding of how Fannie 
Mae's underwriting guidelines compare to other non-Fannie Mae underwriting engines 
(CLUES, LP, etc.). 



3.2.1. DU, Delivery, Pricing Integration 
3.2.1.1. DU and Delivery Integration 

3.2.1.1.1. Sellers will have the ability to transfer certain loan data that was 
originally keyed into DU into the Delivery System. This transfer of data can 
be done on a single loan (i.e. Web Ul) or a multiple loan basis (i.e. batch). 

3.2. 1.1.2. Delivering a loan Using the Delivery Application 

For loans that were previously underwritten in DU, the seller will have 
the ability to transfer this data to the Delivery System when delivering a 
loan to Fannie Mae. 
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When a seller is keying in loan data into the new Delivery application, 
they will have the option of selecting the "DU Data" flag. This flag will 
be available for all submission types (web Ul. batch submission). 
When the "DU Data" flag is set to "Yes", and there is a valid DU Case 
ID, the Delivery Application will automatically populate DU data into the 
Delivery "Loan Submission" screen. DU data that is populated in the 
Delivery "Loan Submission" screen will be uniquely identified on the 
screen so that a user will know the data is from DU (i.e. the section will 
be italicized or shaded). The seller can review this data to ensure that 
they actually want to use the DU data. Sellers will have the ability to 
update any of the data elements in this section if necessary. 

Note: If the user is keying in loan data, or uploading loan data into the 
Delivery Web Ul, and the "DU Data" flag is set to "Yes" and there is a 
valid DU Case ID, Delivery will automatically retrieve the data from the 
DU data store (real time). If the seller is submitting loan data via 
Delivery batch, the DU data will be automatically populated into the 
Delivery loan file. 

If the "DU Data Flag" is set to "No", the user will be required to include 
all information via the data upload or manually key the data into the 
Delivery Ul. In addition, if the seller is submitting data via batch and 
the "DU Data Flag" = "No", then the DU data will not be extracted- the 
seller will be required to supply this information. 

In the event the DU Case ID is invalid (does not exist in the DU 
database), the system will ignore the "DU Data" flag and no data will 
be populated. 

3.2.1 .1 .3. Delivering a Loan from DU OTW 

Sellers will have the ability to deliver a loan from the Delivery application 
as well as Desktop Underwriter on the Web (DU OTW). Delivering a 
loan from DU OTW will work as follows: 

After the seller successfully underwrites a loan, the DU OTW application 
will provide the seller with an option to deliver the loan. DU OTW will 
display a hyperlink stating "Deliver Loan Now" If the seller decides to 
deliver the loan from DU OTW and clicks the "Deliver Loan Now" 
hyperlink, a new browser will be launched and the Delivery "Loan 
Submission" screen will be presented to the user. The DU data that 
applies to the delivery of the loan will automatically populate the 
"Delivery Loan Submission" screen. The DU Case ID will also be 
automatically populated in the Delivery "Loan Submission Ul". As stated 
in the "Delivering a Loan from Delivery" section, the DU data will be 
uniquely identified on the screen so that a user will know the data is from 
DU (i.e. the section will be italicized or shaded). The seller can review 
this data to ensure that they actually want to use the DU data. Sellers 
will have the ability to update any of the data elements in this section if 
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necessary. 

It is important to note that DU OTW will not have Delivery functionality. 
Selecting the "Deliver Loan Now" hyperlink actually transfers the user to 
the Delivery application. 

3.2.1.2. DU Loan - Underwriting and Data Compare 

The Delivery application will notify a seller when the loan data being delivered differs 
from the data that was underwritten in DU. This purpose of this new edit is to warn a 
seller when certain data between Delivery and the DU underwriting file do not match. 
In addition, this edit will proactively notify sellers when they may encounter a price 
adjustment. Data from DU and Delivery that affect the DU underwriting decision and 
pricing will be compared. If there is a difference in the data, the loan will be re- 
underwritten in DU. 

3.2. 1.2.1. DU/Delivery Data Editing 

Delivery loan data and DU underwriting data will be compared at the time of 
Delivery. Specifically, this compare will occur at the time the Delivery edits are run. 
The DU/Delivery data compare will be done for all loans regardless of loan 
execution type. The only prerequisite is that the loan was previously underwritten in 
DU. The seller will be required to supply a valid DU Case ID. If the DU Case ID is 
valid, the system will automatically retrieve the underwriting data from DU and 
perform the comparison. If the DU Case ID is invalid, a fatal edit will be displayed 
to the user stating: 

"DU Case ID Invalid. Loan must be underwritten using a Fannie Mae approved 
underwriting engine. Please supply valid DU Case ID or enter approved 
underwriting engine code". 

A valid (Fannie Mae) approved underwriting engine must be supplied in order for 
the loan to be delivered. 

If a loan was previously underwritten in DU and the seller is Delivering a loan where 
the critical underwriting/pricing data does not match (see attachment 1 for critical 
underwriting/pricing data), the loan will be sent to a DU underwriting engine to be 
re-underwritten. In the event the DU underwriting decision is different than the last 
DU underwriting decision, the new DU/Delivery Data Compare Edit will display the 
following message to the seller: "Delivery and DU Data Do Not Match- Are you sure 
you want to continue?" 

Note: Last DU underwriting decision is defined as the last DU decision stored on 
the DU Case File for a given loan number 

This requirements document intentional does not identify where the loan data 
comparison will take place (DU or Delivery). 

Depending on the results of the underwriting decision that was derived from the 
data supplied at Delivery, the message will be customized. The following is the 
logic on how the decision will be customized: 
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The following edit can be customized to the extent of the other Delivery Edits (See 
Delivery Appendix F). 



Results of DU/Delivery Data Compare 


Message to Seller (appended to edit) 


Underwriting Decision Worse 


The data submitted at Delivery has caused a change in the 
underwriting decision, which will impact Reps & Warrants, 
and/or Pricing. You can waive Reps & Warrants or go ahead 
and pay the new price.** 


Underwriting Decision Better 


The data submitted at Delivery has impacted the pnce of the 
loan. Please review Price, (no override required) 



**For any loan where the seller agreed to waive reps & warrants, or agrees to a 
price change, the Delivery System will capture the Seller Number and Fannie Mae 
Loan Number, User ID (of person who agreed to waive reps & warrants or price 
change), and the date/time stamp (when the reps & warrants were waived or price 
change was acknowledged). 



If the key underwriting and pricing data attributes match, the loan will not be re- 
underwritten. 
3.2.1.3. Non-DU Loan Underwriting 

In an effort to promote the use of Desktop Underwriter and facilitate Fannie Mae 
internal underwriting engine research, all loans that have not been previously 
underwritten in DU will be sent to a DU underwriting engine to be underwritten 

3.2.1.3.1. Non-DU Loan Underwriting and Editing 

All loans that are delivered to Fannie Mae via on-line Ul, file upload, or batch 
submission where the Underwriting Engine ID does not equal DU will be sent to 
DU for underwriting. The underwriting decision will be displayed to the seller as 
information text only. The edit that will be displayed to the user will state: 

"If this loan was underwritten in DU, the decision would be a <insert DU decision 
here>" 

This edit will be set to information only and may not necessarily be displayed to all 
Fannie Mae sellers. As with any edit, this edit will conform to the Delivery Edit 
specifications (customized by seller, program, and seriousness). 

3.2.2. Delivery/Pricing Integration 

The Delivery application will provide sellers with an "All In" Price for all loans. This "All 
In" price will be displayed to the seller at the time of Delivery via the Delivery system 
"Data Submission" Ul or via a batch submission summary report (see Delivery 
Functional Requirements) 

3.2.2.1 . Components of "All In" Price 
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Depending on the loan execution type, the Delivery System will display different 
components of a price to the seller. At the time a loan is successfully entered into 
Delivery, the seller will have the ability to view the "all in" price for a loan(s). The 
"all in" price will be available at the time the loan(s) are run through the inventory of 
Delivery edits. In addition, if the user wants to pre-edit a loan, the Delivery system 
will provide a seller with the "all in" price. The "all in" price will be displayed at the 
seller/product level and will include the following: 



Execution = Cash 

Interest Price (from CAPE) 

+/- ARM Timing Adjustment (Pricing Engine, for ARM loans only) 

+ Credit Adjustments (from Pricing Engine/Deal Management) 
Overall Seller Price Break (from Seller Eligibility System) 
Product Price Break for a Given Seller (from Seller Eligibility System) 

= "All In' Price 

Note: If any of the values above are 0, do not display the entire line item. 
All line items above are displayed in BPS (excluding Interest Price) 

Execution = MBS 

Negotiated G-fee (from Deal Management) 

+/- ARM Timing Adjustment (from Pricing Engine, for ARM loans only) 
+ Credit Adjustments (from Pricing Engine/Deal Management) 
+/- Buyup/Buydown (from Pricing Engine) 

Overall Seller Price Break (from Seller Eligibility System) 
- Product Price Break for a Given Seller (from Seller Eligibility System) 
= *AII In* Price , 

3.2.3. DU Reporting 

Fannie Mae users will have the ability to report on the following DU/Delivery Integration 
related items: 



Report Name 


Description 


Delivery Re-Underwriting Summary 


Identities the number of loans that had to be re* 
underwritten in DU. This report can be broken down by. 

Seller (5/9 digit seller/servicer #) 
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product 

DU decision (is new DU decision better or worse than initial 
underwriting decision)-this piece will total the actual counts 
by decision. 



Non DU Underwriting Report 



Identifies the number of loans and the associated 
underwriting decision for loans that were never 
underwritten in DU. This report will display the DU 
decisions. The report will be broken down by. 



DU decision (subtotal by decision) 



Product 

Seller (5/9 digit seller/servicer*) 



3.3. Committing 

The Committing system will have several different types of interaction with the Delivery system 
for cash executions, including data matching and data upload. Within the Committing system, 
a link will be provided to allow the user to send data directly to the Delivery System for 
delivery. Loans delivered for Best Effort commitments must be matched back to the 
commitment at data submission. 

3 31 The Delivery system should match captured data elements of loans to data 
captured in the Committing system during the Best Efforts registration process. 
Business rules should reflect that data values in the Delivery system must match 
those in the Committing system. 

3 311 Data for comparison should include: Borrower Name, Borrower Social 
Security Number, Property Address, Zip Code (See Delivery Appendix A for 
Data Elements). v 

3 3.1 .2. Data captured during the registration process will be run through DU. A DU 
Case Number can be another identifier provided for matching data. However, 
this will limit matching to only those loans underwritten in DU. It is undecided as 
to whether all Best Efforts commitments will be run through DU-Lite; not all Best 
Efforts loans will have a DU Case Number at this time. 

3.3.1 .3. If data does not match, the seller should be notified to make another 

commitment or apply the loan toward another existing commitment. This is a 
delivery edit. 

3 3 1 .4. If data does not match, the seller should be able to correct captured data if it 
has simply been entered incorrectly by either editing data in the Delivery Ul or 
re-uploading the data. 

3 315. Some data will not be required to match exactly. Best Efforts will be 

providing a list of what data must match and what data should have tolerances 
or variances. 

3.3.1 .6. A report should be generated for Best Efforts to show the price at delivery 
versus the price at commitment. Requirements for this report are to be 
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FMIS will go to the database to retrieve their updates. (See Delivery Appendix D for 
Housing Goals Data Elements and Edit Rules information) 

4. Edits 

Each loan being delivered to Fannie Mae will be checked against data format rules and business 
rules (standard and custom). Business rules are based on the Fannie Mae Charter, Seller/ 
Servicer Guide and other rules specific to product, pool/piece/contract, pricing, commitment, and 
3 rt party (FHA/VA, Ml). Creation and execution of these edits will be managed by the New Edit 
Engine This engine will be available 24/7 to any approved internal or external platform wishing to 
use its services. The Edit engine manager application will comprise a Ul that will enable authorized 
Fannie Mae users to easily maintain all edit rules (add, modify, and delete) without compromising 
the hierarchy of and inter-dependency among rules (See Appendices E and F for information on 
calculations and edit rules). 

4.1. Edit Introduction 

4 11. Users will be able to execute edits against loans via Fannie Mae's online Delivery 
application or by building API's to directly interface with this service from their 

selected platform. 

4.1 .2. The edits will be run with the following hierarchy, product/seller/contract. 

• Format -field 

• Standard 

• Custom: e.g. LTV is over 80% and there is no Ml code - standard edit, but 
Countrywide has a variance so the edit does not fire. 

4 1 3 Upon successful complete of the upload, the data file is edited for format/field edits 
and saved on the Fannie Mae database. The seller can request, during the upload 
process, that the standard and custom edits be run at that time. 

4.2. Editing Requirements 

4.2.1. The system will perform data format edits and the business rule edits necessary to 
delivery loans to Fannie Mae. The business rules are loan, pool/piece, contract 
(including variances) and product specific. 

4.2.2. The system will contain "Pool Rules" that will specify the guidelines for minimum 
balance requirements for various pool/product types. 

4.2.3. The Edit Service will be structured to provide the flexibility to display the maximum 
number of edits to the seller (so that their deliveries will be clean prior to submission) 
OR the minimum number of field/format edits (so internal Fannie Mae personnel 
resolve the edits). 

4.2.4. The system will provide meaningful edit feedback that contains meaningful edit 
messages detailed edit resolution instructions, and ways to resolve the errors. 

4.2.5. If a seller submits loans via file upload/batch submission, then the seller will receive 
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a Batch Status Report that identifies outstandingedits and price information for each 
loan. *X 

4.2.6. The seller and Fannie Mae users will have a real-time view and updates to the data 
in order to resolve data errors before the loan(s) is purchased or securitized. 

4.2.7. Edit Workflow Manager 

The purpose of the Edit Workflow Manager is to allow sellers and Fannie Mae 
personnel a workflow facility that will easily identify and aid in the resolution of 
Delivery related edits. 

The edit Workflow Manager will display all loan delivery related edits that are 
outstanding (edits have been fired and are not resolved) and edits that have been 
resolved in the past 30 days (edits have fired but have been resolved by Fannie 
Mae or the seller). All edits that are in the "resolved" status will automatically be 
eliminated from the Edit Workflow Manager 30 days from the edit resolution date. 

4.2.7.1 . The Edit Workflow Manager will allow the user the ability to view all edits 
using the following filter criteria: 

• Seller Number (5 or 9 digit#) 

• Fannie Mae Loan Number 

• Pool Number 

• Transaction Type 

• Deal ID 

• Data Submission ID 

• Data/Loan Submission Date (single date or range) 

• Edit Type (short description-user can select one or more of these) 

• Edit Severity 

• Edit Date 

4.2.7.2. The Edit Workflow Manager will display the following data elements to the 
user. 

• Seller Number (5 or 9 digit#) 

• Seller Name 

• Fannie Mae Loan Number 
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• Pool Number 

• Transaction Type 

• Deal ID 

• Loan Data Submission ID 

• Loan Data Submission Date 

• Edit Type (Short Description) 

• Edit Date (this date will be the edit resolution date if edit has been 
resolved) 

4 2 7 3. Certain data elements displayed in each row returned in the Edit Workflow 
Manager will contain hyperlinks. These data elements are: 

• Fannie Mae Loan Number - if clicked will bring up the submitted loan 
information. 

• Edit Type - Will give clear and concise information on the edit, why it 
fired, and what the seller needs to do to fix the data. *Note: this is help 
text information that will ensure the seller understands the edit definition 
and what they need to do to fix it. 

4 2 7 4 If the edit is a warning, the seller does not have to do anything. Edits that 
' ' fire that are warnings will be logged in the loan's edit audit/history on the loan. 
Edits with a severity equal to warning will automatically disappear from the Edit 
Workflow Manager once the loan is purchased or pooled. 

4 2 7 5 If the edit is overrideable, the seller will have the option of overriding the 
' ' edit All overrideable edits will be logged in the loan's edit audit/history. As 
stated in the Audit section, the user ID, user name, and date/time stamp will be 
captured when any edit is overridden. 

4 2 7 6 If the edit is non-overrideable (fatal), the seller must re-submit new data to 
resolve the edit. Every time new data is submitted, the system will rerun the 
business edits. As stated in the Audit section, the user id, user name, date/time 
stamp will be captured in the loan's audit/history for every fatal error. 

4 2 7 7 The user will have the ability to manually request the loan's format business 
edits to be renin. As stated above, whenever new data is received on a loan, 
the format and business edits will automatically be rerun. 

4.2.7.8. Sellers can edit their loans using our Ul. This is accomplished by submitting 
loans via batch. 

4 2 7 9 If the seller calls our edit service via batch submission, then the system will 
" ' create a detailed edit batch report. This edit batch report will be available on-line 
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and will contain the following information: Seller Number, Fannie Mae loan 
Number, Pool Number, Transaction Type, Data Submission ID, Edit Type, Edit 
Severity, Edit Date. 

4.2.7.1 0. A seller will have the ability to look up their Edit Batch Reports by Data 
Submission Date. 

4.2.7.1 1 . When the system displays the edits for a loan online, a user must be able to 
easily move back and forth between the edit description, edit help text and loan 
data report. 

4.2.7.12. Internal authorized users will be able to waive or modify edits based on the 
following criteria: 

• By Seller Number 

• By Contract 

• By Pool/Loan 

• By Data Submission ID 

4.2.7.13. All edits must have effective dates and versions. In addition, they must 
show the last change date and last change user ID for an audit log. Multiple 
levels should be available as the edits could be modified several times a day. 
Once modified, the edits should be tested prior to moving them to production. 

4.2.7.14. If a rule is dependent on a specific date (i.e. pool issued date), use the date 
to apply the rule that is in effect. 

4.2.7.1 5. If a rule is not dependent on a date, use the current system date to identify 
which rule to apply. 

4.2.7.16. An audit trail of all edit changes will be logged, saved and available for 
review. 

4.2.7.17. The edit rules need to specify what business function they apply to: 

• All 

• Committing 

• Delivery 

• Post Purchase Adjustment 

• Servicing 

• Securitization 



FannieMae 



20 



Delivery Narrative 



4.2.7. 1 8. Provide the ability to track edit failures after submission to Fannie Mae for 
further processing. 

4.2.7.19. Derived data calculations and other processing logic are initiated as part of 
the edit request. 

4.2.7.20. Derivations may need to be set up by product 

4.2.7.21 . Derived information that is required to be displayed on the various screens 
' throughout the Ul will be populated. 

4 2 7 22 Provide an "editing utility" that allows sellers to upload data into the delivery 
system for editing purposes only. This data does not have to be stored in the 

database. 

4.2.8. Edit Service Manager - Maintenance 

The Edit Manager will include a Ul that will enable authorized internal Fannie Mae 
users to easily enter and maintain all edit rules (add, modify and delete). The following 
describes the edit maintenance manager application. m 

4.2.8.1 . Authorized Fannie Mae users will log into the system to initiate the rule 
maintenance Ul. 

4.2.8.2. Users will be presented with options for Searching, Copying, Adding, and 
Deleting rules. 

4 2 8 3 The search functionality will be flexible so that the user can search through 
existing edits by any supported criteria, such as edit ID, key words, data 
elements, range of values, author, etc. 

4.2.8.4. User will be able to perform add, modify and delete actions on any selected 
edits from the search results. 

4 2 8 5 The system will provide a "Save As" functionality that copies the whole logic 
of an existing rule based on which the user can add new rules without having to 
build complicated rules from scratch, i.e. copy, modify and save as. 

4.2.8.6. Following is the basic functionality for creating a new edit: 

4.2.8.6.1. Copy: Copy and modify an existing edit and save as a new edit. 

4 2 8 6.1 .1 . When the user wants to create a new edit by copying and 

modifying they will first need to search for an edit that they believe has 
similar logic than the rule they intend to create. Once the rule is 
identified, they will select the rule and select the copy function. The 
system will then ask them to enter a different and unique edit ID and 
short descriptive title. The process will continue as indicated in 
section 4.1.3.2.6.3. 
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